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Abstract.  Computer  aid  for  software  evolution  is  needed  for  more  effective  software  development,  particularly  in 
contexts  where  changes  to  large  systems  must  be  made  rapidly.  This  paper  addresses  computer  aid  for  the  evolution 
of  requirements  models  and  high  level  software  designs.  We  present  an  improved  method  for  automatically 
merging  changes  to  software  designs  expressed  via  annotated  dataflow  diagrams  and  hierarchical  decomposition. 
This  improvement  addresses  the  structure  of  the  design  as  well  as  the  system  behavior  the  design  implies.  We  also 
present  an  improved  method  for  automatically  reporting  and  repairing  conflicts  between  structural  changes.  These 
methods  can  be  applied  to  the  informal  dataflow  diagrams  commonly  used  in  requirements  modeling  and  software 
design  as  well  as  to  the  more  specific  executable  design  representations  used  in  the  computer-aided  prototyping 
system  CAPS. 

Keywords: 


I.  Introduction 

Our  goal  is  to  provide  computer  aid  for  software  evolution,  particularly  in  the  critical  early 
stages  of  determining  requirements  and  software  architectures.  Expected  benefits  include 
automated  assistance  for  combining  different  changes  to  a  proposed  design,  assessing  their 
consistency  and  reconciling  structural  conflicts  between  changes.  Reliable  tool  support  for 
change-merging  would  also  facilitate  distributing  design  tasks  on  a  large  software  develop¬ 
ment  project  to  a  group  of  engineers  working  concurrently. 

The  technology  to  achieve  this  is  emerging  [6,  8],  and  a  significant  amount  of  work  has 
been  done  on  developing  change-merging  models  and  building  automated  change-merging 
tools  for  imperative  languages  [3,  7,  17,  26],  as  well  as  for  data-flow  languages  [2,  9,  10, 

II,  12]  and  specification  languages  [4,  5]. 

This  paper  presents  an  improved  change  merging  method  for  hierarchies  of  annotated 
dataflow  diagrams.  This  method  addresses  design  structure  in  addition  to  system  behavior. 
The  results  apply  to  a  range  of  notations  that  have  been  widely  used  in  requirements  analysis, 
design  of  software  architectures,  and  computer-aided  software  prototyping.  Our  results  have 
a  potential  impact  on  tool  support  for  evolution  in  all  of  these  contexts. 

Software  evolution  dominates  many  aspects  of  software  development,  and  tools  that  sup¬ 
port  aspects  of  evolution  such  as  change  merging  are  useful  in  a  variety  of  situations.  Change 
merging  is  needed  to  coordinate  concurrent  effects  of  teams  of  designers,  particularly  in  the 
contexts  of  developing  large  systems  and  rapid  prototyping.  Changes  to  several  different 
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aspects  of  a  large  system  are  often  developed  concurrently,  because  it  would  take  too  long 
develop  the  changes  one  after  another.  During  iterative  development  of  software  prototypes, 
alternative  versions  of  a  prototype  are  often  developed,  each  of  which  contains  a  portion  of 
the  desired  capability.  Because  these  prototypes  can  be  large,  tools  that  automatically  deter¬ 
mine  the  differences  between  the  alternative  versions  and  produce  a  new  version  exhibiting 
the  significant  behavior  modifications  from  each  are  desirable. 

Software  change-merging  is  also  applicable  to  software  maintenance  activities  [13].  If  a 
software  system  has  been  developed  using  the  computer-aided  prototyping  system  (CAPS) 
or  other  languages  and  systems  that  provide  a  semantically  safe  change-merging  capability, 
different  versions  of  that  software  can  be  automatically  updated  with  changes  made  to  the 
base  version  via  a  change-merging  tool. 

Other  potential  uses  of  this  technology  are  in  the  areas  of  software  reuse  and  reengineer¬ 
ing.  In  software  reuse,  complex  reusable  components  that  contain  more  functionality  than 
is  required  for  the  application  can  be  retrieved  from  the  software  repository.  The  desired 
functionality  can  be  isolated  using  graph  slicing  by  taking  the  slice  of  the  complex  compo¬ 
nent  with  respect  to  the  output  streams  desired.  The  resultant  slice  will  contain  all  parts  of 
the  complex  component  that  affects  those  output  streams. 

In  reengineering,  if  a  program  written  in  some  high-level  language  can  be  translated  into 
the  prototyping  language  PSDL,  then  the  evolution  support  capabilities  of  CAPS  [1,  20, 
21]  can  be  applied  to  update  designs  in  which  significant  subsystems  are  realized  by  legacy 
code.  In  addition  to  enabling  parallel  exploration  of  different  enhancements  to  a  legacy 
system  that  exists  in  a  single  configuration,  a  change-merging  capability  could  be  useful 
in  propagating  enhancements  from  a  base  version  of  a  software  family  to  all  of  the  other 
configurations  in  the  family.  For  example,  each  configuration  in  the  family  could  be  tailored 
to  a  different  operating  environment. 

In  [  1 1  ] ,  a  change-merging  method  was  defined  that  is  semantics-based  and  guarantees  that 
if  a  conflict-free  result  is  produced,  it  is  semantically  correct.  This  is  significant  because  it 
allows  different  pieces  of  a  large  prototype  to  be  developed  independently  and  integrated 
with  complete  assurance  of  the  correctness  of  the  integration.  An  initial  implementation  of 
this  method  is  described  in  [  12],  This  tool  uses  dataflow  graph  slicing,  analogous  to  program 
slicing  [25],  to  determine  the  affected  parts  of  an  enhanced  version  that  are  different  from 
the  base  version.  It  then  combines  the  affected  parts  of  the  modified  versions  with  the 
preserved  part  of  the  base  version  to  produce  the  change-merged  version. 

A  drawback  of  the  initial  method  is  that  it  works  only  on  flat  graphs  with  no  hierar¬ 
chical  decomposition.  This  was  done  to  guarantee  correct  slicing.  In  practice,  software 
prototypes  are  designed  using  hierarchical  decomposition  to  provide  better  understanding 
and  maintainability.  The  current  implementation  of  the  method  can  expand  such  designs 
into  equivalent  flat  graphs,  but  currently  provides  no  automated  way  for  aggregating  the 
change-merged  graphs  back  into  a  hierarchical  structure  consistent  with  the  designer’s  orig¬ 
inal  intent.  The  result  is  executable,  but  not  understandable,  because  the  original  design 
structure  is  lost.  This  prevents  the  tool  from  being  used  on  very  large  software  projects,  the 
very  projects  it  was  intended  to  support. 

An  automated  method  for  reconstructing  the  hierarchical  design  structure  is  needed  to 
make  change-merging  more  attractive.  Such  a  method  is  the  main  contribution  of  this 
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paper.  We  provide  a  model  and  algorithm  for  automatic  reconstruction  of  decomposition 
hierarchies  for  change-merged  graphs.  This  extension  to  the  previously  developed  method 
increases  automation  support  for  the  prototype  designer,  and  makes  the  results  more  under¬ 
standable. 

The  method  was  originally  developed  to  support  rapid  prototyping,  because  the  issues  of 
repeated  changes  and  multiple  versions  are  particularly  pressing  in  that  context.  The  method 
is  also  applicable  in  other  contexts,  such  as  supporting  the  evolution  of  requirements  models 
and  architectures  for  large  software  systems. 


2.  Motivating  Context:  Computer-Aided  Prototyping 

Computer-aided  prototyping  is  an  evolutionary  software  development  paradigm  that  over¬ 
comes  the  weaknesses  of  traditional  software  development  methods  by  increasing  customer 
interaction  during  the  requirements  engineering  phase  of  development.  It  provides  exe¬ 
cutable  specifications  that  can  be  evaluated  for  conformance  to  real-time  requirements,  and 
produces  a  production  software  system  in  a  fraction  of  the  time  required  using  traditional 
methods.  Rapid  prototyping  allows  the  user  to  get  a  better  understanding  of  requirements 
early  in  the  conceptual  design  phase  of  development.  It  relies  on  software  tools  to  rapidly 
create  and  demonstrate  concrete  executable  models  of  selected  aspects  of  a  proposed  sys¬ 
tem  to  enable  users  to  assess  and  validate  the  model  early  in  the  development  process.  The 
prototype  is  rapidly  reworked  and  redemonstrated  to  the  user  over  several  iterations  until 
the  designer  and  users  have  confidence  in  a  precise  view  of  what  the  system  should  do.  This 
process  produces  a  validated  set  of  requirements  which  become  the  basis  for  designing  the 
final  product  [20]. 

The  prototype  can  also  be  transformed  into  part  of  the  final  product.  In  prototyping  meth¬ 
ods  like  the  one  supported  by  CAPS,  the  prototype  is  an  executable  shell  of  the  final  system, 
containing  a  subset  of  the  system’s  ultimate  functionality  and  a  high  level  representation  of 
the  software  architecture  for  the  final  product.  After  the  design  of  the  prototype  is  approved 
by  the  customer,  the  missing  functionality  is  added  and  the  system  is  delivered.  In  this 
approach  to  rapid  prototyping,  software  systems  can  be  delivered  incrementally  as  parts  of 
the  system  become  fully  operational. 

Change-merging  is  an  integral  part  of  the  rapid  prototyping  method.  In  the  prototype  de¬ 
sign  part  of  the  process,  multiple  variations  of  a  large  prototype  are  likely  to  be  developed. 
This  can  happen  when  different  development  teams  are  working  on  enhancing  different  as¬ 
pects  of  a  system,  or  when  different  possible  solutions  to  a  problem  are  explored  in  different 
ways.  In  the  first  case,  it  will  certainly  be  necessary  for  the  separately  developed  pieces  of 
the  prototype  to  be  combined  into  a  single  system  before  execution  for  the  customer.  In 
the  second  case,  the  customer  may  desire  a  system  containing  some  or  all  of  the  aspects 
contained  in  each  solution.  In  this  case,  these  different  prototypes  must  be  sliced  to  capture 
the  significant  parts  of  each  variation  and  then  change-merged  to  materialize  the  desired 
combination.  Our  change-merging  method  will  allow  these  combinations  to  be  done  au¬ 
tomatically,  ensuring  that  the  resultant  prototype  is  semantically  consistent  with  all  of  the 
input  variations.  If  the  changes  to  the  semantics  of  the  prototype  are  not  compatible,  then 
our  method  will  identify  the  parts  of  the  prototype  containing  the  conflicts.  This  technology 
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encourages  the  designer  to  explore  different  solutions  to  a  problem,  and  to  spread  the  de¬ 
velopment  workload  in  a  large  project  with  more  confidence  in  the  subsequent  integration 
of  these  independent  efforts. 


3.  Prototyping  System  Description  Language 

The  change-merging  method  described  in  [12]  and  extended  here  has  been  implemented  for 
use  in  the  CAPS  development  system.  It  is  designed  to  operate  on  software  prototypes  writ¬ 
ten  in  the  Prototyping  System  Description  Language  (PSDL)  associated  with  CAPS.  PSDL 
is  a  high  level  specification  and  design  language  which  can  be  translated  into  executable 
code. 

PSDL  represents  software  systems  as  generalized  dataflow  diagrams  annotated  with  tim¬ 
ing  and  control  constraints  [19].  The  notation  is  executable  and  has  a  formal  semantics 
[18]  that  is  a  compatible  refinement  of  informal  dataflow  diagrams  traditionally  used  in 
software  design.  A  PSDL  prototype  is  a  hierarchical  network  of  components.  Each  com¬ 
ponent  consists  of  two  parts:  a  specification  and  an  implementation.  The  specification  of 
a  component  defines  its  interface,  and  the  implementation  contains  either  a  PSDL  graph 
implementation,  or  a  reference  to  a  programming  language  implementation.  The  PSDL 
graph  implementation  contains  a  set  of  operators,  a  set  of  data  streams  through  which  the 
operators  communicate  with  one  another,  and  a  set  of  control  and  timing  constraints  which 
specify  restrictions  on  the  execution  of  the  operators  or  data  streams.  These  graph  imple¬ 
mentations  are  constructed  using  a  top-down  approach,  where  each  level  of  decomposition 
refines  a  composite  operator  at  the  previous  level.  This  decomposition  provides  under- 
standability  for  complex  designs.  The  programming  language  implementation  is  written  in 
any  high-level  programming  language  like  Ada  or  C  that  is  supported  by  the  environment. 
A  more  complete  description  of  PSDL  is  available  in  [19],  and  computational  models  for 
PSDL  are  available  in  [12,  18,  22], 


4.  Ancestor  Chain  Model  of  Design  Structure 

We  would  like  to  apply  past  approaches  to  software  change-merging  to  the  domain  of 
software  decomposition  structures.  These  approaches  work  on  special  kinds  of  lattices 
that  are  also  Brouwerian  or  Boolean  algebras  [7],  To  apply  these  approaches,  we  need 
a  refinement  ordering  on  the  set  of  all  possible  designs.  Several  examples  of  refinement 
relations  are  shown  in  Figure  1 .  Possible  types  of  refinements  include:  ( 1 )  adding  additional 
operators  to  the  prototype,  (2)  decomposing  an  atomic  operator  into  a  composite  operator, 
(3)  grouping  related  atomic  operators  under  a  composite  operator,  and  (4)  providing  a  name 
for  a  composite  operator.  A  difficulty  is  that  most  of  the  intuitively  acceptable  refinement 
orderings  on  software  decomposition  structures  fail  to  qualify  as  lattices  because  they  have 
multiple  minimal  upper  bounds,  as  shown  in  Figure  2.  Nodes  3-6  are  all  minimal  upper 
bounds  for  nodes  1  and  2.  Nodes  3  and  4  are  proper  and  completely  defined  decomposition 
structures  whose  existence  and  correspondence  to  reality  are  not  in  doubt.  Their  greatest 
lower  bound  is  node  7,  which  fails  to  be  a  common  upper  bound  for  nodes  1  and  2.  This 
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Figure  1.  Examples  of  possible  refinements  of  program  designs. 


Figure  2.  Multiple  minimal  upper  bounds  on  program  designs. 


demonstrates  that  nodes  1  and  2  cannot  have  a  least  upper  bound.  Having  no  least  upper 
bound  means  a  unique  automated  choice  of  the  preferred  design  structure  is  not  possible  in 
the  general  case. 

This  implies  that  the  most  obvious  model  of  the  problem  is  inadequate  and  that  we  need 
to  consider  different  points  of  view  on  the  nature  of  the  information  contained  in  a  software 
decomposition.  The  key  insight  that  leads  to  a  solution  is  that  the  essential  information 
about  a  software  decomposition  is  not  an  attribute  of  the  substructure  of  a  component,  as 
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Figure  3.  Refinement  ordering  IZ  over  ancestor  chains. 


was  assumed  in  developing  the  refinement  ordering  illustrated  in  Figure  3,  but  rather  an 
attribute  of  its  context ,  namely  the  location  of  the  component  in  the  hierarchy. 

This  insight  leads  to  the  ancestor  chain  model  of  software  structure  which  is  the  basis 
for  our  change-merging  method.  In  this  model,  the  position  of  a  component  in  a  design 
hierarchy  is  represented  as  a  sequence  of  ancestor  names,  where  the  sequence  (A,  B,  C,  D) 
means  that  the  parent  of  the  current  node  is  D,  D’s  parent  is  C,  C’s  parent  is  B,  and  the  top 
level  operator  is  A.  We  call  these  sequences  ancestor  chains. 

We  define  the  domain  of  proper  ancestors  to  be  the  set  of  all  finite  sequences  of  com¬ 
ponents,  partially  ordered  by  the  prefix  ordering.  Formally  this  ordering  is  defined  by 
x  c  y  3z[y  jc  ' —  z],  where  ^  denotes  concatenation  of  sequences.  An  example  of 
such  a  refinement  ordering  is  shown  in  Figure  3.  This  ordering  has  the  structure  of  a  tree, 
with  its  root  at  the  empty  sequence.  The  tree  has  infinite  depth.  Its  branching  factor  at 
each  node  is  equal  to  the  number  of  all  possible  module  names;  it  is  conventional  to  assume 
that  this  is  infinite  as  well.  This  partially  ordered  set  is  a  meet  semi-lattice  that  has  greatest 
lower  bounds,  but  lacks  least  upper  bounds  for  pairs  of  sequences  where  one  is  not  a  prefix 
of  the  other.  This  incompleteness  in  the  abstract  model  corresponds  to  concrete  reality  for 
informal  dataflow  diagrams  as  well  as  for  the  CAPS  system:  since  PSDL  does  not  allow 
an  operator  to  have  more  than  one  parent,  two  ancestors  in  different  ancestor  chains  cannot 
have  a  least  upper  bound  that  is  a  legal  program,  or  a  proper  element  of  the  domain  of 
software  decompositions. 

We  note  that  the  bottom  element  of  the  semi-lattice  has  a  double  interpretation.  The  empty 
sequence  serves  as  a  proper  element  when  it  is  used  to  represent  the  ancestor  chain  of  the 
root  component  of  the  decomposition.  It  also  has  the  more  familiar  purpose  of  representing 
undefined/incomplete  information  in  its  role  as  the  ancestor  chain  of  all  possible  components 
that  are  not  yet  included  in  a  given  design  decomposition. 

To  do  change-merging  over  this  refinement  ordering,  we  embed  it  in  a  lattice  like  the  one 
shown  in  Figure  4.  We  do  this  by  adding  improper  data  elements  representing  least  upper 
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<[  1> 


Figure  4.  Extended  ancestor  lattice. 


bounds  for  all  sets  of  incomparable  proper  elements  and  adding  them  to  the  set.  These 
improper  elements  (e.g.  {a)  u  (b))  represent  merging  conflicts  that  can  be  considered  to  be 
abstract  representations  of  error  messages. 

Since  our  goal  is  to  define  a  change-merging  operation,  we  extend  the  domain  of  proper 
ancestors  in  a  way  that  makes  it  easy  to  add  a  pseudo-difference  operation  that  makes  the 
resulting  lattice  into  a  Brouwerian  algebra.  The  standard  way  to  do  this  is  to  work  with 
downwards-closed  sets  in  the  partial  ordering  (i.e.,  sets  S  for  which  x  €  S &a  ^  x 
a  e  S),  where  the  ordering  Q  denotes  the  sequence  prefix  ordering  illustrated  in  Figure  3. 
Figure  4  abbreviates  the  set  representation  by  showing  only  the  maximal  elements  of  each 
set  with  respect  to  the  C  ordering. 

We  define  the  domain  of  extended  ancestors  as  follows.  The  elements  of  the  extended 
domain  are  downwards-closed  sets  of  proper  ancestor  chains,  where  each  set  represents  the 
least  upper  bound  of  all  the  proper  elements  in  the  set.  A  proper  element  of  the  extended 
domain  represents  a  proper  ancestor  chain,  and  consists  of  a  set  containing  that  proper 
ancestor  chain  and  all  of  its  prefixes.  The  ordering  of  the  extended  domain  is  the  subset 
relation.  This  ordering  produces  a  full  lattice  structure.  The  corresponding  least  upper 
bounds  are  set  unions,  and  the  corresponding  greatest  lower  bounds  are  set  intersections. 
The  lattice  operations  are  well  defined  because  the  union  and  intersection  of  two  downwards- 
closed  sets  are  both  downwards  closed. 

We  note  that  the  ordering  on  extended  ancestors  agrees  exactly  with  the  sequence  prefix 
ordering  on  proper  ancestors,  and  that  the  greatest  lower  bounds  and  the  least  upper  bounds 
also  agree  with  those  in  the  sequence  prefix  ordering  in  the  cases  where  these  bounds  exist 
in  the  sequence  prefix  ordering.1  Thus  this  construction  gives  a  consistent  extension  of  the 
sequence  prefix  ordering,  and  the  proper  ancestor  domain  can  be  embedded  in  the  extended 
ancestor  domain. 

The  pseudo-difference  operation  —  that  comes  with  this  construction  is  the  downwards 
closure  T>C  of  the  set  difference.  The  pseudo-difference  and  downwards  closure  operations 
are  defined  as  follows. 
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Figure  5.  Examples  of  lattice  operations  in  the  set  representation. 


*-y  =  VC(x-y) 

DC(S)  =  {a  :  Ancestor  |  3x[x  e  S&a  c  jc]} 


It  is  well  known  that  the  downwards  closed  sets  ordered  by  set  inclusion  form  a  Brouwe- 
rian  algebra  with  respect  to  a  pseudo-difference  operation  defined  in  this  way  ([23],  Theo¬ 
rem  1.14).  A  definition  of  Browerian  algebras  is  given  in  the  appendix  and  a  discussion  of 
some  of  the  known  properties  of  Brouwerian  algebras  and  pseudo-difference  operations  can 
be  found  in  [7, 24].  An  executable  specification  of  the  lattice  and  change-merging  operations 
is  given  in  Figures  6  and  7.  These  specifications  are  expressed  in  OBJ3  [14, 15,  16], 

The  domain  ComponentJd  contains  unique  names  for  components;  its  definition  is  not 
shown  because  it  has  no  interesting  properties .  The  domain  Component  contains  only  proper 
components,  with  a  trivial  ordering:  all  distinct  components  are  incomparable.  The  domain 
Ancestor  contains  only  proper  ancestor  chains,  which  are  finite  sequences  of  components 
ordered  by  the  prefix  ordering.  These  proper  domains  are  extended  with  artificial  elements 
that  are  least  upper  bounds  of  finite  sets  of  proper  elements  and  represent  merging  conflicts. 
The  extended  domains  are  denoted  by  Component!  and  Ancestor!.  The  OBJ3  keyword 
prec  declares  the  relative  precedences  of  the  infix  operators;  lower  numbers  indicate  tighter 
binding.  The  equations  define  the  lattice  ordering  and  the  meet  and  join  operations  for  the 
extended  domains. 

The  change-merging  operation  a[b]c  represents  the  result  of  combining  the  change  from 
the  base  version  b  to  the  enhancement  a  with  the  change  from  b  that  results  in  a  different 
enhancement  c.  Some  examples  of  software  decomposition  merges  implied  by  these  equa¬ 
tions  are  shown  in  Figure  8.  The  ancestor  chain  merge  for  node  d  is  not  shown  in  the  figure 
because  node  d  is  not  present  in  the  merged  implementation  graph,  so  that  its  position  in 
the  hierarchy  does  not  have  to  be  computed  by  the  decomposition  merging  algorithm. 
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obj  DECOMPOSmONXATTICE  is 
protecting  COMPONENT  JD . 
sorts  Component  Component!  Ancestors  Ancestors!  . 
subsort  Component  <  Component!  <  Ancestors!  . 
subsort  Component  <  Ancestors  <  Ancestors!  . 
op  C  :  Component  Jd  -*■  Component . 

***  Constructor  for  building  components  from  componentJds 
op  -L  :  ->  Ancestors  . 

***  An  empty  ancestor  list,  for  root  components  and  unused  components, 
op  _ ,  _ :  Ancestors  Ancestors  ->  Ancestors  [assoc  id:  _L  prec  1] . 
op  _ ,  _ :  Ancestors!  Ancestors!  -*■  Ancestors!  [assoc  id:  ±  prec  1] . 

***  Ancestor  list. 

op  _  c  _ :  Ancestors!  Ancestors!  —*■  Bool  [prec  4] . 

***  Lattice  Ordering. 

op  _  u  _ :  Component  Component  — >  Component!  [comm  prec  2] .  ***  assoc 
op  _  u  _ :  Ancestors!  Ancestors!  ->  Ancestors!  [comm  prec  2] .  ***  assoc 
***  Least  Upper  Bound. 

op  _  n  _ :  Ancestors!  Ancestors!  -*■  Ancestors!  [assoc  comm  prec  2] . 

***  Greatest  Lower  Bound. 

vars  C  C'  C"  :  Component .  vars  EC  EC'  EC"  :  Component!  . 
vars  A  A'  A"  :  Ancestors  .  vars  EA  EA'  EA"  :  Ancestors!  . 

***  Ordering 
eq  CCC'  =  C==C'. 
cqA  c  EA  u  EA'  =  A  c  EA  or  A  c  EA' . 
eq  EA  u  EA’  c  EA"  =  EA  c  EA'  and  EA'  c  EA"  . 
eq  I  c  E  A  =true  . 
eq  EA  c  _L  =  EA  ==  ±  . 

eq  (EC,  EA)  c  (EC',  EA')  =  if  EC  c  EC'  then  EA  Q  EA'  else  false  fi . 
***  Least  Upper  Bounds 

eq  ((EC  u  EC'),  EA)  =  (EC,  EA)  u  (EC',  EA) . 
eq  (EC,  (EA  U  EA’))  =  (EC,  EA)  U  (EC,  EA') . 
cq  EA  u  EA'  =  EA'  if  EA  C  EA' . 

***  Greatest  Lower  Bounds 
eq  C  n  C'  =  if  C  ==  C'  then  C  else  J.  fi  . 
eq  EA  n  (EA'  u  EA")  =  (EA  n  EA')  u  (EA  n  EA")  . 
eq  _L  n  EA  =  _L  . 

eq  (EC,  EA)  n  (EC',  EA')  =  ((EC  n  EC'),  (EA  n  EA')) . 

endo 


Figure  6.  OBJ3  equations  for  constructing  ancestor  lattice. 
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obj  DECOMPOSmON.CHANGEJMERGING  is 
protecting  DECOMPOS ITION X A 1'  1'lCE  . 

op  _  —  _ :  Ancestors!  Ancestors!  ->  Ancestors!  [prec  3] .  ***  Pseudo-difference 
op  _  [  _  ]  _ :  Ancestors!  Ancestors!  Ancestors!  -*■  Ancestors!  [prec  4] .  ***  Merge 

vars  C  C'  C"  :  Component .  vars  EC  EC'  EC"  :  Component!  . 
vars  A  A'  A"  :  Ancestors  .  vars  EA  E A'  E A"  :  Ancestors!  . 

***  Pseudo-Difference 
eq A—EA  =  if  A  tz  EA  then  _L  else  A  fi . 
eq(£A  U  EA')—EA"  =  (EA—EA")  u  (EA'—EA") . 

***  Merge 

eqEA[EA']EA"  =  ( EA-EA ')  u  (EA  n  EA")  u  ( EA"-EA ') . 

endo 


Figure  7.  OBJ3  equations  for  merging  ancestor  chains. 


5.  Change-Merging  Algorithm 


The  initial  algorithm  for  semantics-based  change-merging  of  flattened  PSDL  prototypes 
was  described  briefly  in  [11],  and  exhaustively  in  [12].  This  algorithm  takes  three  PSDL 
prototypes  as  input;  a  base  version  and  two  modified  versions.  The  change-merge  operation 
applied  to  the  implementation  graphs  uses  graph  slicing  to  identify  the  preserved  part  of 
the  base  and  the  affected  parts  of  the  modified  versions.  To  do  the  graph  slicing  accurately 
and  guarantee  that  all  dependencies  are  found,  the  hierarchically  decomposed  graphs  are 
expanded,  yielding  equivalent  flat  implementation  graphs.  The  result  of  the  change-merge 
is  a  PSDL  program  with  a  completely  expanded  flat  implementation  graph.  The  initial 
algorithm  produced  a  correct  merged  graph  whenever  no  conflicts  were  reported.  This  graph 
was  converted  into  a  PSDL  program  that  can  be  translated  into  an  executable  representation 
of  the  merged  version  and  is  useful  for  demonstrating  the  behavior  of  the  merged  version. 
However,  the  designer’s  original  decomposition  was  lost  in  the  process,  so  the  result  of  the 
merge  was  not  a  suitable  basis  for  human  review  or  further  enhancement. 

This  section  presents  an  extension  of  the  initial  PSDL  change-merging  algorithm  based  on 
the  ancestor  chain  model  of  section  4.  The  extended  algorithm  does  everything  the  initial 
algorithm  does,  then  separately  determines  the  design  structures  of  the  three  versions, 
combines  them,  and  uses  the  result  to  transform  the  merged  flat  graph  back  into  a  new 
hierarchical  design.  The  final  step  of  the  initial  algorithm  constructs  a  PSDL  prototype  from 
the  merged  graph  in  a  subprogram  called  bui  Id-prototype.  In  the  extended  algorithm,  this 
subprogram  is  replaced  with  the  subprogram  decompose-graph,  shown  in  Figure  9.  This 
function  operates  on  the  change-merged  program  produced  by  the  original  algorithm  along 
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a:  <>[<>10 

b  :  (a)[(a)]() 
c  :  ( ab)[(ab)](a )  = 

e:  ( abc)[{abcd)](ac )  = 


/  :  ( a)[(ab)](ac ) 
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±  u  (a)  u  (ac) 
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Figure  8.  Examples  of  change-merging  ancestor  chains. 


with  the  three  given  versions  of  the  implementation  graphs  as  input  and  produces  a  new 
psdl-program  with  a  hierarchically  decomposed  graph. 

The  decompose -graph  subprogram  uses  an  array  indexed  by  the  nodes  in  the  graph  to 
hold  the  ancestor  chain  for  each  node.  Each  element  of  the  array  is  initialized  by  the  function 
mergejances  tor  .chains,  which  calculates  the  merged  ancestor  chain  for  each  node  in  the 
merged  flat  graph  according  to  the  equations  in  Figure  7.  The  ancestor  chain  of  each 
node  with  respect  to  each  of  the  three  given  versions  of  the  PSDL  program  is  determined 
by  the  function  findMncestorjchain  which  recursively  searches  the  tree  of  graphs  in 
each  of  the  given  decomposition  structures  until  it  finds  the  node,  and  then  determines  the 
ancestor  chain  by  retracing  the  path  back  up  to  the  root  of  the  tree,  recording  each  parent 
in  the  chain  on  the  way.  When  the  loop  terminates,  the  array  holds  the  merged  ancestor 
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Algorithm  decompose-graph(M  ERGE:  in  psdLprogram;  A,  BASE,  B:  inpsdl-graph) 
return  psdLprogram; 

ANCESTORS:  array (nodeid)  of  extended-ancestor; 

MERGE_CHAIN,  A-CHAIN,  B-CHAIN,  BASE-CHAIN:  extended-ancestor; 
NEW-PSDL:  psdLprogram; 
begin 

for  every  node  N  in  MERGE  loop 

A-CHAIN  :=  find-ancestor_chain(A,  N); 

B-CHAIN  :=  find_ancestor_chain(B,  N); 

BASE-CHAIN  :=  find_ancestor_chain(BASE,  N); 

merge_ancestor_chains(A_CHAIN,BASE_CHAIN,B_CHAIN, MERGE_CHAIN); 
ANCESTORS(N)  :=  MERGE-CHAIN; 
end  loop; 

report_conflicts(ANCESTORS) ; 

ANCESTORS  :=  resolve-Conflicts(ANCESTORS); 

NEW-PSDL  :=  reconstruct_prototype(MERGE,  ANCESTORS); 
return  NEW-PSDL; 
end  decompose.graph-. 


Figure  9.  Algorithm  decompose-graph. 


chains,  which  can  be  either  proper  sequences  or  improper  ancestor  chains  that  are  least 
upper  bounds  of  two  incompatible  proper  ancestor  chains.  The  subprogram  for  reporting 
conflicts  report-conflicts  scans  the  array  of  ancestor  chains  and  reports  and  describes 
a  conflict  for  each  of  the  improper  chains  in  the  array,  if  there  are  any.  The  subprogram 
resolve-conflicts  repairs  any  conflicts  in  the  graph  according  to  the  methods  described 
in  the  next  section,  resulting  in  an  array  that  contains  only  proper  ancestor  chains.  The 
last  subprogram  reconstruct -prototype  builds  the  new  graph  according  to  the  recreated 
design  structure  and  replaces  the  flat  graph  in  the  merged  prototype  with  the  new  graph. 

6.  Conflict  Resolution  and  Error  Messages 

Hierarchical  decompositions  provide  grouping  information.  The  grouping  information  aids 
human  understanding,  but  does  not  affect  function.  This  implies  that  partial  recovery  of 
the  designer's  intent  can  be  acceptable,  as  long  as  the  recovered  information  is  compatible 
with  all  of  the  decisions  that  were  made.  Even  in  cases  where  changes  to  the  grouping 
information  implicit  in  the  decomposition  structures  conflict,  sensible  results  can  always 
be  produced  by  taking  the  maximal  proper  grouping  that  is  consistent  with  the  result  of 
the  merge  in  the  cases  where  it  produces  an  improper  element  of  the  ancestor  chain  lattice 
representing  a  merging  conflict.  This  element  can  be  computed  conveniently  from  the 
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(acd)[{ac)]{ace)  =  {{acd)-{ac))u({acd)n{ace))u{{ace)—{ac)) 
=  { acd )  u  {ac)  u  {ace) 

—  {acd)  u  {ace)  (***conflict***)  =  {ac{d  u  e)) 
{acd)  n  {ace)  =  {ac).  (***resolution  of  conflict***) 


Figure  10.  An  example  of  a  resolved  conflict. 


normal  form  for  ancestor  chains  defined  by  the  equations  in  Figure  6.  In  this  normal  form 
each  lattice  element  is  represented  as  the  least  upper  bound  of  a  set  of  one  or  more  proper 
ancestor  chains.  For  practical  applications,  the  size  of  this  set  will  be  at  most  one  more 
than  the  number  of  merging  operations  that  were  used  to  construct  the  lattice  element,  and 
if  conflicts  are  resolved  by  each  merging  operation,  the  set  will  have  at  most  two  elements. 
If  the  result  of  merging  ancestor  chains  is  a  conflict  term,  compute  the  maximal  compatible 
proper  ancestor  chain  by  replacing  all  least  upper  bounds  in  the  normal  form  with  greatest 
lower  bounds  and  simplifying.  The  result  is  the  strongest  proper  term  consistent  with  both 
changes.  An  example  is  shown  in  Figure  10. 

The  change-merging  method  for  decomposition  structures  given  in  this  paper  is  a  total 
operation  that  always  produces  a  result.  Sometimes  the  result  is  a  proper  element,  which 
represents  a  conflict-free  merge,  and  sometimes  it  is  an  improper  element,  which  represents 
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a  conflict  between  incompatible  changes.  The  equations  given  in  Figure  6  can  be  used  as 
rewrite  rules  to  transform  all  improper  elements  into  a  normal  form  that  looks  like  the  least 
upper  bound  of  a  set  of  irredundant  proper  elements.  This  representation  can  be  used  to 
produce  informative  error  messages. 

The  basic  structure  of  our  ancestor  chain  model  associates  context  descriptions  with 
each  operator.  Consequently,  the  error  message  can  specify  which  operator  has  a  design 
structuring  conflict.  The  normal  form  specifies  exactly  which  decisions  about  the  placement 
of  the  operator  in  the  hierarchy  conflict,  so  that  this  information  can  be  provided  with  the 
error  message.  Finally,  in  some  cases  the  nature  of  the  conflict  can  be  further  localized,  by 
using  the  following  equation  to  further  transform  conflict  terms: 

(C,  EA)  u  (C,  EA')  =  (C,  ( EA  u  EA')) 

This  transformation  factors  out  common  prefixes  of  improper  ancestor  chains,  thus  getting 
rid  of  information  that  does  not  contribute  to  the  conflict  and  producing  a  more  specific 
error  diagnosis.  The  results  of  doing  this  are  shown  both  algebraically  and  graphically  in 
Figure  10.  The  error  message  resulting  from  the  transformed  conflict  term  for  the  example 
can  be  rendered  in  English  as  “structural  conflict:  both  D  and  E  are  required  to  be  direct 
parents  of  operator  F”. 


7.  Conclusion 

Our  main  result  is  an  extension  to  the  change-merging  algorithm  of  [11]  that  preserves 
the  significant  design  structure  as  well  as  the  significant  behavior  of  the  given  versions. 
This  is  an  improvement  over  the  previous  method  because  the  automatically  constructed 
merge  can  be  used  as  a  basis  for  further  analysis  and  prototype  enhancement  as  well  as  for 
execution  and  prototype  demonstration.  The  previous  algorithm  produces  a  version  that  is 
suitable  only  for  execution  and  demonstration,  because  the  structure  of  the  design  is  lost  by 
the  transformation  it  applies.  This  paper  shows  how  that  design  structure  can  be  recovered 
after  the  behavioral  transformation  is  applied. 

Our  change-merging  method  and  algorithm  are  formulated  in  terms  of  PSDL,  the  proto¬ 
typing  language  used  by  the  CAPS  system.  Because  the  PSDL  model  is  a  generalization 
and  extension  of  the  informal  dataflow  diagrams,  the  same  change-merging  method  can 
also  be  applied  to  the  informal  dataflow  diagrams  commonly  used  in  software  requirements 
and  software  design.  Our  results  can  therefore  be  used  to  extend  the  degree  of  computer 
support  for  many  variations  of  this  widely  used  notation,  such  as  those  of  Yourdon  and 
DeMarco. 

A  supplementary  result  of  the  paper  is  an  approach  to  error  diagnosis  and  repair  that 
applies  to  change-merging  conflicts.  The  approach  exploits  the  improper  data  elements 
introduced  by  the  extension  of  the  proper  data  domain  to  the  Brouwerian  algebra  needed 
to  support  the  change-merging  domain.  The  improper  data  elements  are  used  both  for 
providing  a  specific  description  of  the  nature  of  the  conflict,  and  for  deriving  the  most 
informative  conflict-free  design  structure  that  is  compatible  with  the  overconstrained  value 
representing  the  conflict.  We  note  that  the  Brouwerian  algebra  introduced  in  [24]  to  better 
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explain  the  algorithm  for  merging  changes  to  while-programs  given  in  [17]  also  contains 
analogous  improper  data  elements,  and  conjecture  that  these  elements  can  also  be  exploited 
to  support  improved  conflict  diagnosis  and  possibly  some  form  of  conflict  resolution. 


Appendix — Definitions 

This  appendix  contains  formal  definitions  for  some  of  the  standard  algebraic  concepts  used 
in  the  body  of  the  paper. 

Definition  1.  A  lattice  is  an  algebra  (L,  u,  n)  such  that  the  set  L  is  closed  under  the 
operations  u  and  n  and  the  following  properties  are  satisfied  for  all  jc,  y,  and  z  in  L: 

•  x  n  x  =  x  and  x  u  x  =  x 

•  jc  n  y  =  y  n  jc  and  x  U  y  =  y  u  x 

•  x  n  (y  n  z)  =  (jc  n  y)  n  z  and  jc  u  (y  u  z)  —  (jc  u  y)  u  z 

•  x  n  (jc  u  y)  =  x  and  x  u  (x  n  y)  =  x 


Definition  2.  The  partial  ordering  c  associated  with  a  lattice  is  defined  by  x  E  y 
x  n  y  =  x  for  all  x,  y  in  L. 

Definition  3.  A  Browerian  algebra  [23]  is  an  algebra  (L,  u,  n,  — ,  T>  such  that 

•  (L,  U,  n)  is  a  lattice  with  the  greatest  element  T, 

•  The  set  L  is  closed  under  the  operation  — ,  and 

•  jc— y  c  z  O  x  E  y  u  z  for  all  jc,  y,  z  in  L. 


Notes 

1.  The  least  upper  bound  xuy  with  respect  to  the  sequence  prefix  ordering  exists  if  and  only  if  x  c  y  or  y  c  x. 
In  the  first  case  x  u  y  =  y  and  in  the  second  x  u  y  =  x.  The  greatest  lower  bound  x  n  y  always  exists  and  is 
the  longest  common  prefix  of  the  sequences  x  and  y. 
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